Skip to content

FP8 KV-Cache Compatibility for Hybrid vLLM Models#1899

Open
YJHMITWEB wants to merge 10 commits into
NovaSky-AI:mainfrom
YJHMITWEB:fp8-rl-kv-cache
Open

FP8 KV-Cache Compatibility for Hybrid vLLM Models#1899
YJHMITWEB wants to merge 10 commits into
NovaSky-AI:mainfrom
YJHMITWEB:fp8-rl-kv-cache

Conversation

@YJHMITWEB

Copy link
Copy Markdown

Summary

This PR enables vLLM's existing fp8_e4m3 KV-cache mode for hybrid attention/Mamba models that use nested cache structures. It does not change weight quantization, parameter storage, or weight sync

Changes

Change Explanation
Nested cache traversal Recursively discovers tensor leaves in list, tuple, and mapping cache structures used by hybrid attention/Mamba models.
Scoped FP8 reset compatibility Temporarily presents a flat tensor list only while vLLM initializes FP8 KV-cache scales, then restores the original nested structure.

Quality

All FP8 runs show perfect alignment with the BF16 baseline.
Qwen3.5-4B runs: https://wandb.ai/sky-posttraining-uc-berkeley/qwen35_4b_dapo_mainclean_fp8align_fastbatch_bf16_fp8_20260630?nw=nwuserjinghanyao1

Qwen3.5-9B runs: https://wandb.ai/sky-posttraining-uc-berkeley/qwen35_9b_h100_tp2_bf16_fp8_prready_20260709?nw=nwuserjinghanyao1

Qwen3.5-35B-A3B runs: https://wandb.ai/sky-posttraining-uc-berkeley/qwen35_35b_a3b_fp8_amaxeps_20260705?nw=nwuserjinghanyao1

@jinghanyao1-hub jinghanyao1-hub self-assigned this Jul 14, 2026

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces support for serialized blockwise FP8 weight synchronization and persistent FP8 parameter training, alongside memory optimization features like CPU-resident microbatches and a colocated worker memory barrier with hard eviction. It also adds a compatibility patch for vLLM FP8 KV-cache sleep/wake resets on nested cache entries. The feedback highlights an optimization opportunity in the weight extraction process, suggesting that blockwise FP8 quantization should only be performed on rank 0 to avoid redundant GPU/CPU compute and memory usage on other ranks.

Comment thread skyrl/backends/skyrl_train/workers/megatron/megatron_worker.py
@YJHMITWEB
YJHMITWEB force-pushed the fp8-rl-kv-cache branch 4 times, most recently from fa82f40 to 8e47ee8 Compare July 16, 2026 18:39
@erictang000 erictang000 self-assigned this Jul 20, 2026
PPORayActorGroup stored `pg` and `num_gpus_per_actor` on self but nothing ever
read them back (the constructor already passes both directly to
_initiate_actors). Drop the two dead assignments; the constructor params are
unchanged.
Make the previously opt-in `cpu_resident_microbatches` behavior the only path
and remove the config flag. Each microbatch is now moved to the device just
before its forward step (in MegatronModelWrapper.forward_step), instead of
moving the whole mini-batch up front. This caps resident input-tensor memory at
one microbatch and is a no-op when a tensor is already on device.

The per-microbatch transfer is the single choke point for every forward and
forward-backward pass, so the up-front `.to(device)` calls in the worker are
removed; nothing downstream reads the mini-batch tensors on-device after the
microbatch loop (only chunk()/BatchIterator, which slice on CPU, and metadata).

Removes the MegatronConfig field, the wrapper constructor param, the worker
plumbing, and the CLI-override test for the flag.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants